stanfordfandomcom-20200214-history
Highly Interactive Treeview
= Highly Interactive Tree-view = Johnny Zhou & Juho Kim CS349W - Autumn '08 What is the interaction? We’ve all seen and become second-naturedly familiar with the typical DHTML tree-view navigation found in many existing web applications, exemplified by http://www.treeview.net/. This typical tree-view allows the user to expand and collapse nodes in a practical and familiar, but very limited manner. These traditional tree-views are used primarily for navigation around a website, whether it’s within a navigation sidebar or a site map, which hardly anybody uses. However, in today’s Web 2.0 world emphasizing dynamic and rich user interactions with web pages, the traditional 1990s rudimentary tree-view is well overdue for an upgrade. Motivated by existing tree-view interactions, Highly Interactive Tree-view was designed to provide more interactions and direct manipulation features as well as on-the-fly editing of the tree (Screenshot shown on the right). In order to visualize the tree in more interactive way, pixel-level access to the HTML element is necessary, since we do not want any external plugins installed to interact with the tree. The tree-view is built on the HTML canvas element, which has recently become standardized. Traditional HTML rendering lacked support for pixel-level access, but the canvas changes that completely. With the help of canvas element, Highly Interactive Tree-view provides a means for advanced desktop-like drawing and animations inside your browser window without the need for plugins such as Flash or SilverLight. Our tree provides the following features new to the realm of tree-views: * Fundamental expanding/collapsing of nodes * Parses an input XML file used to populate the data of the tree * Every node in the tree is draggable around the page arbitrarily. * Node size dynamically adjusted to fit the amount of the node label * Real-time connection line-rendering between parent and child nodes * Visual cues as to which nodes are expandable and which are leaves * Cursor changes depending on context - e.g. 4-way arrows for drag and drop, zooming indicator when tree is being zoomed, and hand on mouse hover * Zooming and panning of the entire tree * Overloaded mouse-click functionality ** Static left-click expands and collapses a node. ** Left-click and drag moves a node or pans the entire canvas. ** Static right-click on the node opens a URL associated with the node. ** Static right-click on the empty space fits the tree within the current canvas size. ** Right-click and drag zooms in or out on the entire tree (up zooms in, down zooms out) * A supplementary section displays the relevant data from each node in the XML input file This new style of a tree-view is very well suited for a novel way of navigation within a web application. The fact that each node can store any kind of text information as well as links or URL, it can replace lists and categories that are link-based. It is flexibly applicable for managing interactive bookmarks, a sitemap, or table of contents for HTML tutorials. Finally, it can certainly be used for generic tree displays of arbitrary data and linkage, such as DOM tree or hierarchical diagram. How is the interaction implemented? The application takes an XML file as an input, and processes and visualizes the tree with treeview.js, making use of HTML canvas element and Processing.js library. The data that represents the tree is parsed from an input XML file with an appropriate schema, whether locally in relation to the web server or from any arbitrary URL. The rest of the interaction is purely JavaScript-based, leveraging the Canvas HTML element that has been standardized in HTML 5 and is supported by the latest Gecko and Webkit rendering engines. We utilize one existing JavaScript library, processing.js. Processing.js is a pure JavaScript port of the open-source Processing language (www.processing.org), which provides a great foundation API for bitmap drawings, visualization tools, animations, and interactions. It is an interesting approach in a sense that strictly-typed Processing language is almost perfectly ported on typeless Javascript. It gives us the API for implementing the shape and text drawing facilities used in the tree. The Processing.js API provides an override-able function draw() which is looped over repeatedly based on the set frame-rate. The vast majority of the rendering tasks of the tree-view is done within this function. The highly-interactive tree-view starts off by parsing an inputted XML file and recursively building corresponding JavaScript objects representing each of the nodes of the tree. Each node is stored as a JavaScript object containing all of the necessary member data, including label, URL, and an array of child nodes. This structure gives us a nice way of iterating recursively through all of the nodes in the tree for whatever action we want to accomplish on the tree. Because the XML file input can provide any arbitrary data for each node, each object also contains pointers to that data, for use determined by developers using this tree. After XML parsing is complete, root node in the page is rendered. With an XML parse tree, the application registers appropriate event handlers for each appropriate element, including mouse-down, mouse-up, and mouse-drag. User interaction is determined by detecting the type of event, mouse button used, position of the cursor, and whether a certain node has been selected or not. On a left-click, the node is expanded, and we calculate the appropriate fan-out positions of all child nodes, display them by making them visible, and connect them to the parent with a drawn line. On a left-click followed by dragging, the selected node is repeatedly moved and redrawn in real-time based on the difference between the current mouse position and its original position upon first being clicked. Of course, we also redraw the line linking the node to any children or parents as well. When a node is then collapsed, all ancestor nodes and connections are made invisible and inactive, but state is still maintained, so that expanding the node again will display all ancestors nodes in their last positions. When the user mouses over an expandable node, its color changes to notify the user that it is indeed expandable. Zooming is mapped to right-click drag behavior, and is accomplished via the processing.js scale() function. We recalculate the width, height, and position every time zooming behavior is detected. Panning the tree is accomplished via left-click and drag on empty space on the canvas. On mousedown, we determine if the user clicked on an empty space, and just like we did for dragging and dropping a particular node, we iteratively drag and drop all of the active nodes and their corresponding line links. There are other interactions not mapped to specific mouse events. We provide functions for expanding and collapsing all nodes, as well as an auto zoom-to-fit feature that places all visible nodes in a clean and fitting manner on the canvas, without any overlap for example. This is done via some simple looping computation that determines the best fit for each visible node based on the current size of the canvas and the number of nodes visible on screen. For convenience, zoom-to-fit is associated with right-click on the empty space. Additionally, we resize each node if the text it contains is longer than the box itself. The canvas element provides a function, mozMeasureText(), that returns the width in pixels of the text drawn, which we used to determine the appropriate size of the containing node box. How is this interaction encapsulated as a reusable component? This highly-interactive tree-view is very simple to reuse. All that is required to use this tree is to include the two JavaScript files, the address of an input XML file with the appropriate base schema, create an empty canvas element inside an arbitrary HTML page, and make a call to the displayTree() method. For instance, the following complete HTML page displays the default tree as defined by the argument XML file: A sample XML file defining the tree is shown below: ... ... ... ... ... ... Each node in the XML file is required to contain the label, url, and children elements. But beyond that, the developer is free to add any arbitrary elements to each node, and use them accordingly in a page. The Treeview API provides access to each of the tree node objects and any arbitrary data encapsulated in the node. It is very easy to hook into and moreover, is highly customizable. We provide a wide array of API calls for customizing the look and feel of the tree, including but not limited to getting and setting node width/height/color, canvas width/height/color, mouse hover/active color, border/line color, etc. These, amongst others, give the second-party developer a wide array of options for specifying how the tree should look. In order to maximize reusability, we opened a project website hosted by Google Code to help anyone interested in applying Highly Interactive Tree-view. The website, located at http://code.google.com/p/interactive-treeview/ includes getting started tutorial, examples, XML tree format definition, and the complete API reference. Source repository can be accessed publicly to facilitate customization, distributed in MIT License. Light-weight Javascript files make it a more attractive solution. Normal version requires only 60KB of Javascript (38KB of Processing.js and 21KB of Treeview.js), and minified (13KB of Treeview.js) and/or gzipped version can reduce the loading time even more, making it easier to apply in various applications. How will this tree integrate with the server-side part of the web application? The visual aspects of the tree are entirely browser-based. An XML file, however, provides the data representing the tree. This XML file could be at any arbitrary location on the web, or it could also sit on the same machine as the web server. The server-side, henceforth, would provide the data representing the tree, as well as potentially serving the linked-to pages and other arbitrary data associated with each node. For very large XML files and their corresponding trees, there is clear potential for building the tree on-demand, that is, via dynamic AJAX requests. Instead of pre-populating every node in the tree, we can load the necessary loads from the server as they are expanded. Because this application is entirely JavaScript based, essentially any existing web framework ranging from other JavaScript libraries to full web application frameworks such as Rails can use it right out of the box. Any web applications based on server-side framework can easily add tree-view to the front-end, much like a component. Analysis of Strengths, Weaknesses and Practicality This highly interactive tree-view is a novel way of displaying any generic kind of tree structure in a browser. It provides the user very clean and intuitive ways of interaction with the tree, as well as utilizing the data associated with each node. The interaction is entirely browser-based, and the tree data is fed by an input XML file from an arbitrary source. Our tree provides a desktop-like real-time direct manipulative interface for what was once a boring and mundane DHTML tree-view. The tree is perfect for modern site maps in large web applications, as well as a navigation pane in the main application itself. We’ve been accustomed to linear navigation links, but we can certainly extend this with the highly interactive tree-view to provide the user with a more intuitive and user-friendly navigation interface for any large website. As seen from the screenshot on the right, Amazon category system can be visualized in a Tree-view, providing more interactive navigation. It is very easily reused and customized with arbitrary data, requiring only a simple empty canvas element and a single function call. Each node in the tree can contain any additional data beyond the label and child nodes, and our API provides access to the node objects, and thus there is great flexibility for the effects of selecting a node in the tree. There are weaknesses, however, that makes it difficult to apply Highly Interactive Tree-view in some applications. First of all, it is likely not to be very scalable for large trees. JavaScript has a tendency to be slow, and if the tree contains hundreds or thousands of nodes, the response times may be severely affected. Beyond response times, having many nodes on the screen will definitely result in clutter, but this can be managed by zooming and panning, along with some user support. Moreover, having many nodes will take up a lot of screen space, an issue that is certainly mediated by the ability to pan and zoom, but there will nevertheless be a clutter problem with a large number of nodes. Additionally, it is not universally supported. Only the latest Firefox 3.0+ and Opera 9.5+ browsers are officially supported, along with the latest beta WebKit nightly builds. This is due entirely to the lack of the canvas support in the other browsers. Finally, the tree is heavily "paint" oriented, meaning it is essentially drawing the tree bitmap-style. The text is also drawn, so traditional text manipulation such as highlighting is not supported. Most importantly, we don't have any DOM structure for the tree. Its structure must be handled entirely within the corresponding JavaScript objects. All in all, the highly interactive tree is a very practical second-generation version of the traditional linear tree-view. It is well suited for all kinds of navigation tasks, as well as a generic tree display of any arbitrary data. Its weaknesses are limited, and it is very simple to reuse and customize, and is built upon standardized browser facilities found within the latest rendering engines. It is a new generation tree-view that brings the interaction on par with Web 2.0 trends, involving intuitive direct manipulation and tangible interactions. Category:test Category:dsfq